System and method for delivering versatile security, digital rights management, and privacy services from storage controllers

ABSTRACT

A method for providing enhanced security features in a storage device involves partitioning a storage media in the storage device into a hidden partition and a storage partition in the storage media. A base class is written to the hidden partition. A security provider base class is instantiated from the base class. The security provider base class is adapted to control access to the storage media.

CROSS REFERENCE TO RELATED APPLICATION(S)

This application is a continuation in part of pending application Ser.No. 09/912,931, filed on Jul. 25, 2001, entitled “METHODS AND SYSTEMSFOR PROMOTING SECURITY IN A COMPUTER SYSTEM EMPLOYING ATTACHED STORAGEDEVICES,” which is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

The present invention generally relates to methods and systems forsecuring computer systems. More particularly, the present inventionrelates to methods and devices containing a security partition and adisc drive architecture for securing information in a system, which maybe connected to a networked environment.

Computer operating systems or platforms play a central role inelectronic commerce, as well as in day-to-day business operations forlarge and small companies alike. As more computer systems becomeconnected to networks (private and public), the need to secureinformation has become critical. Unfortunately, traditional operatingsystems provide limited security.

To protect information, most business have taken steps to protectindividual server platforms. However, no overall correspondingimprovement in client platforms has been implemented, in part, becauseof the variety of client platforms and because of the cost. While the PCplatform provides the benefits of flexibility and openness, fuelingexceptional economic growth, the same benefits also expose users tosecurity breaches, such as hackers, viruses, and the like.

It is sometimes possible to detect whether software has been modified,provided that it is known what element of the OS might have beenmodified. However, current computing platform technologies do not allowa local or remote user to test whether a platform can be trusted withsensitive information. For example, a host system can verify that aparticular user is accessing the system, but it is difficult (if notimpossible) to establish with certainty whether the particular user'scomputing platform is a corporate machine and whether it runs therequired software and configurations.

With the advent and widespread deployment of the Internet, thedeficiencies of conventional computer security systems have been exposedand sometimes exploited. A disadvantage of the Internet is that itpermits many ways to infiltrate the perimeter defenses of conventionalcomputer systems. Damaging virus programs, for example, can be injectedthrough firewalls and into a computer system. Generally, infiltration ofthese perimeter defenses can compromise data and computer programs,which can impact derivative capabilities, such as digital rightsmanagement.

While software has been developed to provide some protection on aplatform by platform basis, software-only security implementations aredependent on proper installation and execution. A conventional exampleof such localized computer system security is virus detection software.Virus detection software, however, can be susceptible to exploitationby, for example “spoofing” or “wrappering” strategies. In a compromisedsystem, virus detection software may be made to appear operational, evenwhen it is not operating properly. This highlights a fundamental problemwith conventional computer security systems, namely that the securitysystem operates within the same environment as the operating system.Software security implementations (such as virus detection software) maybe impacted by software that has already been executed on the softwareplatform. The phrase “software platform” as used herein generally refersto the operating environment or operating system (OS). Even tightlycontrolled software cannot vouch for its own integrity. For example, ifmalicious software, such as a virus, has bypassed the perimeter defensesor security features of the OS and has managed to corrupt its operation,the OS cannot be expected to recognize the security breach, reliably.

Furthermore, the operating system environment for many computer systemsis also common, for example, to the Internet environment or to anothernetwork communications medium. Because of the commonality between theclient operating system and the operating environment, many means ofattack on a computer system are available merely by moving computercode, for example, from the Internet to the computer operating system.

Some conventional methods of computer protection may involve specialpurpose security hardware or firmware installed in the BIOS of acomputer system. These methods can establish secondary lines of defenseinternal to operation of a computer system but external to thecomplicated and error-prone operating system environment.

Other conventional computer security systems may include a securitydevice connected to a SCSI bus that protects storage devices on the bus.This type of security system recognizes that the storage device is moresecure while not operating in an environment common to the operatingsystem. However, the SCSI bus of this system exposes all devices on thebus, including the storage devices. Specifically, the SCSI bus exposesall devices on the bus by allowing access to the attached devices.Therefore, effective utilization of a security device attached to a SCSIbus requires intimate operating systems involvement.

Still other computer security systems recognize the benefit of guardingthe storage device at the controller level but are based on sharedprivate keys. Shared private keys are well-known to provide lesssecurity than securing and concealing elements of public-private keyencryption, because authentication keys are shared and are not privateto a single device. This type of system suffers the same problem ofoperating system dependence illustrated above, because it is alsodirected to modification of the file management system of the computeroperating system.

In another type of computer security system, the security perimeterconsists of self-contained software that exports only a simple storageinterface for external access and that verifies the integrity of eachcommand before processing the command. By contrast, most file serversand client machines execute a multitude of services that are susceptibleto attack. Typically, such a system provides for automated recovery to aknown good state, relying on secure storage mechanisms. Unfortunately,this type of system also requires operating systems modification. Theautomated recovery system incorporates complexity and, therefore,vulnerability, approaching that of an OS. Moreover, the automatedrecovery system permits opportunities for the introduction of Trojanhorses, and the like. “Trojan Horse” is a generic term for a virus or asecurity-violating program or script that is disguised as somethingelse. Typically, a Trojan Horse masquerades as a benign program, like adirectory Lister for example, but which contains a trap door or attackprogram that can be used to break into a network.

The ATA Host Protected Area security protocol provides security to acomputer system by hiding a portion of a storage media of a storagedevice during the boot phase of a computer system. In this method, thestorage device hides a portion of the storage media by telling theoperating system that the storage device has less storage space than thestorage device actually has. The undeclared storage space represents anarea of the storage media that is essentially inaccessible to the BIOS.Special BIOS firmware or other special code can have exclusive access tothe hidden or undeclared portion of storage device. As an additionalsecurity measure, the ATA Host Protected Area can require passcodeaccess to this additional amount of storage space. The ATA HostProtected Area was originally designed to provide security assurance inthe form of an enhanced operating system and application crash recoverysystem. For example, the hidden or undeclared portion of the storagedevice can be used to cache a known good version of the system orapplication software, outside the capability of the operating system toaddress. In practice, this restricts access to a portion of the storagedevice to a computer program running either in the main device firmwareor in the operating system environment.

However, the ATA Host Protected Area protocol has a security hole inthat it is still possible to intercept communications with the storagedevice. The hidden ATA Host Protected Area partition of the storagedevice can be revealed, for example, by putting that same disc driveinto another computer that does not reserve the Host Protected space.The passcode, if used, is not retained across power cycles. While theATA Host Protected Area is an acceptable place to protect local backupcode and data from virus-like infections, the ATA Host Protected Area istypically not the best place to conceal data. Furthermore, the onlyauthentication required by ATA Host Protected Area is a “first come,first served, winner take all” type of device authentication.

Still another type of computer security system involves a TrustedComputing Platform (TCP). In general, a trusted platform (TP) is acomputing platform that is trusted by local users and remote entities,including users, software, web sites and all third parties. To enable auser to trust a computing platform, a trusted relationship must be builtbetween the user and the computing platform, which can verify to theuser that an expected boot process, a selected operating system, and aset of selected security features in the computing platform have beenproperly installed and are functioning correctly. An organization calledthe “Trusted Computing Platform Alliance” (TCPA, and later reconstitutedas the Trusted Computing Group, TCG) has defined a specification for theTCP. The TCPA/TCG via the specification advocates that a separatemechanism, called the Subsystem, be used to establish trustrelationships between various modules and components within the systemand with other entities. Generally, the subsystem includes a TrustedPlatform Module (TPM) and software for performing integrity metrics inconjunction with the TPM.

The Subsystem is designed to prevent logical, or software-based attacks.Generally, the Subsystem establishes a hardware-based foundation fortrust, based on a set of integrity metrics, which are defined asmeasurements of key platform characteristics. Specifically, theintegrity metrics are measurements that can be used to establishplatform identity, such as BIOS, boot-loader, OS loader, and OS securitypolicies. Cryptographic hashing techniques are used to extend trust fromthe BIOS to other areas of the platform.

Any type of computing platform (for example, a PC, server, personaldigital assistant (PDA), printer, mobile phone, or any other networkabledevice) may be a trusted platform. A trusted platform is particularlyuseful for mobile platforms that are connected to a network, in part,because physical mobility coupled with connectivity increases the needfor stronger trust and confidence in the computer platform. Inparticular, such connectivity and mobility increases the likelihood ofviruses and of unauthorized access to critical systems. Unfortunately,though the present trusted drive architecture prevents the drive frombeing compromised by logical or software based attacks, the Subsystemmay, optionally, still be compromised by physical means, which canexpose the secrets of the Subsystem.

SUMMARY OF THE INVENTION

In one embodiment, a storage media of a storage device is partitionedinto a hidden partition and a storage partition. A base class is writtento the hidden partition. A security provider base is instantiated fromthe base class. The security provider base class is adapted to controlaccess to the storage media.

In another embodiment, the storage device has a processor and firmwareadapted to access data stored on a storage media. Disc drive firmware iswritten to a controller of the storage device. The storage media of thestorage device is partitioned into a hidden portion and a data portion.A security provider object template is written to the hidden partition.Security providers are instantiated using the security provider objecttemplate. Each security provider is adapted to control access to thestorage device.

A storage device for providing hardened security features has a storagemedia partitioned into a hidden portion and a data portion and has astorage controller adapted to control access to the storage media. Atrusted drive feature is stored in a firmware of the storage controller,and is adapted to authenticate access requests to determine whether eachaccess request can be trusted. A SP base object is stored in the hiddenportion, and is adapted to cooperate with the trusted drive feature tocontrol access rights to data on the storage media.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a perspective view of a disc drive in which the presentinvention is useful.

FIG. 2A is a simplified block diagram of a system according to oneembodiment of the present invention.

FIG. 2B is a simplified block diagram of a system according to anotherembodiment of the present invention.

FIG. 3 is a simplified flow diagram of the creation of a Trusted driveaccording to an embodiment of the present invention.

FIG. 4 is a simplified flow diagram of a customization process providedby an original equipment manufacturer in order to customize securityfeatures of the drive for a particular customer.

FIGS. 5A and 5B illustrate a simplified block diagram of a partitionedstorage media having a hidden partition and security provider objects.

DETAILED DESCRIPTION

FIG. 1 is a perspective view of a disc drive 100 in which the presentinvention may be used. Disc drive 100 can be configured as a traditionalmagnetic disc drive, a magneto-optical disc drive or an optical discdrive, for example. Disc drive 100 includes a housing with a base 102and a top cover (not shown). Disc drive 100 further includes a disc pack106, which is mounted on a spindle motor (not shown) by a disc clamp108. Disc pack 106 includes a plurality of individual discs 107, whichare mounted for co-rotation about central axis 109. Each disc surfacehas an associated slider 110, which is mounted to disc drive 100 andcarries a read/write head for communication with the disc surface.

In the example shown in FIG. 1, sliders 110 are supported by suspensions112 which are in turn attached to track accessing arms 114 of anactuator 116. The actuator shown in FIG. 1 is of the type known as arotary moving coil actuator and includes a voice coil motor (VCM), showngenerally at 118. Voice coil motor 118 rotates actuator 116 with itsattached sliders 110 about a pivot shaft 120 to position sliders 110over a desired data track along a path 122 between a disc inner diameter124 and a disc outer diameter 126. Voice coil motor 118 operates undercontrol of internal circuitry 128. Other types of actuators can also beused, such as linear actuators.

During operation, as discs 107 rotate, the discs drag air under therespective sliders 110 and along their bearing surfaces in a directionapproximately parallel to the tangential velocity of the discs. As theair passes beneath the bearing surfaces, air compression along the airflow path causes the air pressure between the discs and the bearingsurfaces to increase, creating a hydrodynamic lifting force thatcounteracts the load force provided by suspensions 112. The hydrodynamiclift force causes the sliders 110 to lift and fly above or in closeproximity to the disc surfaces.

In general, disc drive controllers and storage subsystem controllerscurrently trust their hosts. Various threats, as outlined above, cancompromise host security and allow unauthorized access to confidentialinformation that is stored on disc drives and on storage subsystems.Therefore, there is a need for improved security of storage devices andstorage subsystems.

Hereinafter, the terms “storage device”, “storage subsystem” and “discdrive” or “disc” are used interchangeably, except where otherwise noted,and include any data storage device that is accessible directly via anetwork or that is installed within a computer system. The storagedevice need not necessarily incorporate a physical “disc”, butpreferably incorporates a place for storage managed by a controller withfirmware.

As used herein, the phrase “computer system” is used to refer to anydevice having a memory storage that can be connected to a private orpublic network, whether directly or indirectly. For example, computersystems include, but are not limited to, desktop computer systems,laptop computer systems, networked computer systems, wireless systemssuch as cellular phones and PDA's, digital cameras includingself-contained web-cams, and/or any reasonable combination of thesesystems and devices.

One solution for improving storage device security involves introducinga sophisticated operating system architecture, such as Unix, Linux,Windows, and the like, into the controller for the storage device.High-end systems, such as Storage Area Network (SAN) systems, haveadopted this approach.

An alternative solution involves building access controls into theresource-limited environments of disc drives and storage subsystemcontrollers. Unfortunately, this technique costs precious additionalphysical controller resources and risks inconvenience to the customerwhen access is denied.

The present invention relates to a system and method for promotingstorage device security using a trusted drive architecture. The “TrustedDrive” design (meaning a drive or storage subsystem controller design)for providing versatile security and digital rights management accordingto the present invention pertains to specific types of hidden data andhidden operations.

FIG. 2A illustrates a simplified block diagram of a system 200 includinga security provider (SP) according to an embodiment of the presentinvention. As shown, the system 200 has a storage subsystem 202 incommunication with a network 204. The network 204 can be of any type,including local area network (LAN), wide area network (WAN), theInternet, ad hoc wireless network, public switched network, and so on.Additionally, the term storage subsystem 202 refers to any devicecapable of connecting (directly or indirectly) to a network 204. Forexample, the storage subsystem 202 may be a storage media internal tocomputer system. Alternatively, the storage subsystem 202 may be astand-alone device capable of connecting directly to a network orattaching as a peripheral device to a personal computer or workstation.

The storage subsystem 202 includes a host operating system 206, whichrelies at least in part on software and data obtained from a storagemedia 208. Typically, the storage media 208 includes firmware 210 thatreads and writes data to and from a data storage portion 212 of thestorage media 208. Additionally, at least a portion of the storagedevice firmware 210 can be rewritten by the operation system, and atleast another portion of the device firmware 210 resists being writtenby the operating system and may be written only using one or more of theconventional hardware methods.

Finally, the storage subsystem 202 may include a hidden partition 214,which can be used to store the SP or elements of the SP required foraccess to data stored in the hidden partition and/or on the data storageportion 212 of the storage device 208. Specifically, the SP may be usedby the storage subsystem 202 to control access to the storage device 208as a whole, and to the data storage portion 212 and the hidden partition214 in particular.

In general, the hidden partition 214 is a contiguous logical set ofblocks in the storage-subsystem 202, which are not acknowledged to theoperating system 206 of the host because these logical blocks are notaddressed by the read/write commands. In other words, the hiddenpartition 214 is hidden precisely because the host operating system 206is not aware that it exists except through commands specialized to thesecurity features. If, for example, the storage subsystem 202 has atotal storage space of four hundred Gigabytes, and two hundred Megabytesare reserved for the hidden partition 214, then the host operatingsystem 206 is informed that the total disk space of the storagesubsystem 202 equals 399.8 Gigabytes. The two hundred Megabyte hiddenpartition 214 is simply not available to the operating system 206 forread/write operations.

The term “partition” is used herein to mean a contiguous grouping ofbytes allocated during low-level formatting of the storage device. Incertain embodiments, “partition” may refer to a contiguous grouping ofmemory blocks of approximately 512 bytes each. Special securitypartitions and the structures and processes that support these securitypartitions are included in the present computer security system.Moreover, the system of the present invention is substantially notdependent on an operating system.

Generally, the persistent data for a Security Provider (SP) is stored ina contiguous, logical set of blocks in the storage subsystem 202. In apreferred embodiment, the contiguous, logical set of blocks in thestorage subsystem 202 constitutes a hidden partition 214. The persistentdata typically includes the name, passcode, and public-private keys forthe SP and for the authorized users of the SP. In otherwords, the SPstores its name and its passcode (the passcode the SP uses to authorizeitself), and its public-private keys, as well as the names, passcodesand public keys of its permitted users. The persistent data is stored inan authority table. An authority record is an entry in the authoritytable for a single user agent. This user agent may represent a realperson, or may represent another SP, a device, or any other entitycapability of providing the proper credentials.

It will be understood that an SP is (for the most part) a completelyself-contained unit that manages its own access control. The SP alsocontrols access to elements within the SP or accessible via firmware tothe SP. The credentials needed for access include the name, thepasscode, and the capability of proving identity by digitally signingand directing information by exchange only to the recipient. Inestablishing the access controls for a SP, the creator can choose toallow access based on knowledge of the SP's name, of a passcode, and/orof private and public keys.

By building the access control to controller resources into the storagesubsystems 202, the cost to the use of physical storage resources can bebalanced against the improved security features. Specifically, theaccess control architecture of the drive can be manipulated externally,scaled as needed from low-end to high-end controller systems, andenhanced dramatically to provide hardened security services.

The phrase “manipulated externally” refers to the fact that accesscontrol parameters can be variously set by the factory, the OEM, theVAR, the Company, and the end user. Access controls can be strong orweak depending on the capabilities desired and on the user's tolerancefor inconveniences associated with access control procedures.

The access control architecture is scalable, meaning that a single modelof access control can be fabricated at low costs. As capabilities areadded to the access control architecture, the costs may increase. Suchincreased capabilities include support for physical access tokens (suchas Smart Card access, digital fingerprinting and the like) and speed(such as encryption hardware and the like).

The development of such security tokens, smart cards, and other similarsecurity features has resulted in standards that can be applied to offerwell-understood, hardened security services to the customer.

Generally, there are three relatively well-known and publicly accessiblestandards for providing such security features. One is the MicrosoftCryptographic Service Provider standard. Another is the RSA SecurityPublic Key Cryptography Standard Number 11 or “Cryptoki”. A third is theclass of ISO 7816 ICC Smartcard standards and their derivatives.

The Microsoft Cryptographic Service Provider standard (MS CSP), producedby Microsoft Corporation of Redmond, Wash., is an example of suchhardened security. The MS CSP carefully defines the special controller(e.g., smart card or special chip) functionality need by the operatingsystem (in this case the Microsoft Windows operating system) forhardened login, named resource access, cross-domain authorization, fileencryption, network encryption, and secure network access for email andInternet services. The MS CSP is designed for environments using tokensand cryptographic chips.

Similarly, for Unix, Linux, and Java operating systems, there is anotherstandard corresponding to the MS CSP standard. For these operatingsystems, the standard is called the RSA PKCS#11 standard, which is astandard developed by RSA Laboratories, a research arm of RSA Securityof Bedford, Mass. “PKCS” is an acronym for Public Key CryptographyStandard.

The class of 7816 ICC Smart Card standards provides more capability andversatility than the CSP or PKCS#11. Where the CSP providescryptographic operations, and PKCS#11 additionally provides storage forcertifications, the 7816 standards and their derivatives additionallyprovide full file system storage with access control that is differentfor different files.

A disc drive or storage subsystem that simply offers MS CSP, RSAPKCS#11, and ISO 7816 services represents a cost effective,well-accepted way to harden the associated operating system againstthreats. Firmware packages that implement the external controller-sideof CSP, PKCS#11, and ISO 7816 are typically in the thirty to sixtyKilobyte range in size.

Distinct collections of security services that share underlying hardwarealready exist and can be referred to as Security Provider Objects or SPObjects. Fundamentally, SP Objects provide access control to controllerresources and storage data. For example, a Controller SP Object providesaccess control to test diagnostics and maintenance programs that run inthe controller. Because there are literally thousands of companies thatprovide host and network security products that can be used to hardensecurity via the MS CSP, RSA PKCS#11, or ISO 7816 standards, the SPObjects are designed to be independent of one another. The SP Objectsare generally self-contained, but they tend to utilize a common toolset.Generally, the SP Object can be considered a self-contained environmentwith its own access controls to its own security resources. This allowsdisc controller resources to be minimized. Specifically, while a discdrive or storage subsystem might be required to support many differentsecurity products, only a small subset of such security products wouldtypically be enabled at any given time. Moreover, no particular SPObject would be enabled “all the time”. A characteristic of the RSAPKCS#11, MS CSP, and ISO 7816 standards are that the operating systemstend to use them in small bursts. For example, when browsing theInternet, the CSP is used only when the user accesses secure web pages(pages utilizing secure socket layer security, for example). Whileaccessing such pages, the CSP is used intensively (with many “calls” persecond), but when not access as secure page, the CSP is not used. Thissecurity access tendency is true for most security applications.

With respect to Trusted Drive implementations, the trusted drive featurecan be referred to as a SP as well. In general, the storage subsystem ordisc drive according to a embodiment of the present invention is adaptedto provide hardened security features, including trusted drive features.

Referring to FIG. 2B, the system 200 is shown as a simplified blockdiagram including a trusted drive feature according to an embodiment ofthe present invention. As shown, the system 200 has a storage subsystem202 in communication with a network 204. The network 204 can be of anytype, including local area network (LAN), wide area network (WAN), theInternet, ad hoc wireless network, public switched network, and so on.Additionally, the term storage subsystem 202 refers to any devicecapable of connecting (directly or indirectly) to a network 204. Forexample, the storage subsystem 202 may be a storage media internal to apersonal computer or a server. Alternatively, the storage subsystem 202may be a stand-alone device capable of connecting directly to a networkor attaching as a peripheral device to a personal computer orworkstation.

The storage subsystem 202 includes a host operating system 206, whichrelies at least in part on software and data obtained from a storagemedia 208. Typically, the storage media 208 includes firmware 210 thatreads and writes data to and from the storage media 208. The storagemedia 208 is divided into a data portion 212 and a hidden portion(hidden partition) 214. In this embodiment, a trusted drive feature 220is embedded in the controller within the firmware 210.

Additionally, at least a portion of the storage device firmware 210 canbe rewritten by the operation system, and at least another portion ofthe device firmware 210 resists being written by the operating systemand may be written only using one or more of the conventional hardwaremethods. In a preferred embodiment, the trusted drive feature 220 isstored in the portion of the firmware 210 that resists being written bythe operating system (non-writeable firmware).

In general, the hidden partition 214 is a contiguous logical set ofblocks in the storage subsystem 202, which are not acknowledged to theoperating system 206 of the host during the boot process. In otherwords, the host operating system 206 is not aware that the hiddenpartition 214 exists. If, for example, the storage subsystem 202 has atotal storage space of four hundred Gigabytes, and two hundred Megabytesare reserved for the hidden partition 214, then the host operatingsystem 206 is informed that the total disk space of the storagesubsystem 202 equals 399.8 Gigabytes. The two hundred Megabyte hiddenpartition 214 is simply not available to the operating system 206 forread/write operations.

Within the hidden partition 214, one or more authority records 216 and abase class 218 are stored. The authority records 216 can be used tostore the SP or elements of the SP required for access to data stored inthe hidden partition and/or on the data storage portion 212 of thestorage device 208. In one embodiment, all authority records 216 can begoverned by a single master authority record. The host. OS 206 is notpermitted to access the SP data stored within the hidden partition 214,except through the trusted drive feature 220. This independence of theSP data from the Host OS 206 provides an important benefit overconventional security methods and systems, namely that the hiddenpartition represents a location on a computer system where informationsuch as a secret can be effectively concealed.

Finally, the hidden portion 214 of the storage device 208 has a baseclass 218, which can be used to specify a SP Base class 222, from whichall of the security provider classes ultimately derive. The base class218 is sometimes referred to as a “root class”, and the SP base class isa “subclass” within a hierarchy of classes of the security provider.Generally, the base class 218 allows the OEM or the manufacturer tospecify a SP base class 222 from which each SP Object can beinstantiated and from which all other SP classes derive. The SP Baseclass 222 provides default methods for an instantiated SP. For example,the SP Base class 222 provides default record data management methodsand a default administration key, which can be used to log into theadministration SP 228 and to configure access controls, which canoverride the default configuration. In other words, the administrationSP 228 can be used to configure the access controls to disallow accessusing the default key and even to change access permissions for theadministration SP 228.

The base class 218 also provides default methods for the secure importand export of entire SPs and parts of SPs and for local replication ofentire SPs within the storage controller based on triggers internal tothe storage controller.

During manufacturing, all trusted drives are initialized with anadministration SP 228 and a “Controller SP Object” (which in thisembodiment is the trusted drive feature 220). The administration SP 224provides access control to the creation, modification, and deletion ofother SP Objects.

Once the administration SP 224 is initialized, it is logged into, andthe controller SP object is initialized with its own access controls.Significantly, it is then possible to deny the administration SP 224 aright to further modify or destroy the controller SP.

As shown in FIG. 2B, in addition to the base SP 222 and theadministration SP 224, other SP objects (elements 226-232) may beinstantiated using the base SP 226, including a public key store 226, alog SP 228, a registry SP 230, public key revocation store 232, a clocktime SP 234, a diagnostics SP 236, a test SP 238, and an external codeSP 240. Access to the administration SP 224 is required for the creationof other SPs on a storage controller.

A public key store 226 is used to cryptographically verify a request fora new SP instantiation. For example, in one embodiment, a SP Object fromthe storage device manufacturer may require a digital signatureassociated with the storage device manufacturer in order to validate arequest for a new SP instantiation. A Computer Associates eTrust SP mayrequire a Computer Associates signature or certificate to validate arequest for a new eTrust SP instantiation. If the storage device doesnot support public key access in the general access controls defined bythe controller SP, no resident authorizing key is required.

In another embodiment, the trusted drive system 200 has a log SP 228type that can track and log the activity of other SPs based on thesuccess or failure of the other SP to gain access to data or tomanipulate data or methods associated with the other SP. The log SP 228incorporates provisions for cyclic logs and all other capabilitiespossible through the general access controls.

In yet another embodiment, the trusted drive system 200 has a registrySP 230 type that provides a standard SP handle (virtual distinguishedname) through which any number of physical copies of a SP Object can belocated and managed. The Registry SP 230 can distinguish and manageMaster SPs from copies of the Master (both local and non-local), and candistinguish and manage specific Master data within an SP so that therecan be a “Master Record” or “Master Value.”

In another embodiment, the trusted drive system 200 is provided with akey and passcode revocation store 232, which checks authorizing publickeys, passcodes and other authentication elements for revocation. Instill another embodiment, the system 200 includes a clock-time SP type234 that can provide a hardened source of clock or elapsed time both toother SPs and to the Host.

In yet another embodiment, the system 200 provides a diagnostics SP 236adapted to provide hardened access control to storage controllerdiagnostics. A test SP 238 may be provided to harden control to storagecontroller testing as appropriate. Additionally, an external code SP 240may be provided to harden access controls to customer provided softwarerunning on the storage controller.

Each of the above-described embodiments may be implemented in a singletrusted drive system 200 (as shown in FIG. 2B). Alternatively, variousSP elements 226-240 may be selected to be included as needed. The baseclass 224 provided in the hidden partition 214 is used to create eachbase SP 222, and the base SP 222 is used to create the SP objects forhardened security. In general, the storage location of the base SP 222and the various SP objects 224-240 may vary. Specifically, the SPobjects 222-240 may all be stored outside of the hidden partition (asshown) or may be stored within the hidden partition. Alternatively, thepublic key store 226 may be stored within the hidden partition 214,while other elements are stored outside of the hidden partition 214 inthe data store 212.

In one embodiment, all of the SP objects 222-240 are provided within thehidden partition 214. In a second embodiment, all of the SP objects222-240 are provided outside of the hidden partition. In a thirdembodiment, the base SP 222, the administration SP 224 and the publickey store 226 are provided within the hidden partition 214, while theother sp objects 228-240 are stored in the data store 212. The specificarrangement of the SP Objects 222-240 depends on the securityimplementation, on the memory allocation for the hidden partition 214,and on various design and implementation issues, such as (for example)whether the OEM will be permitted to instantiate and configureadditional SP objects.

FIG. 3 is a simplified flow diagram illustrating an installation of atrusted drive architecture at the factory. Once the disc drive hardwareis assembled (step 300), firmware is written to the drive controllers orthe storage subsystem controllers (step 302). Generally, the firmwareincludes trusted drive controls and optionally encryption functions.Additionally, in cases where hardware acceleration of cryptographicoperations is desirable, special hardware may be added.

The disc drive or storage subsystem is then powered up (step 304). Ahidden partition is created on the storage media (step 306), and SPObject templates are created and written to the hidden partition (step308). Various versions of trusted drives that offer many instances of SPObjects to many different companies may allocate a large hiddenpartition (as much as a few gigabytes in size). Trusted drives that donot offer Host services or that offer only a few specific Host servicesmay allocate a small hidden partition (as small as a kilobyte, forinstance).

The disc drive or storage subsystem is then initialized with anAdministration SP Object and a Controller SP Object (step 310). TheAdministration SP Object provides access control over the creation,modification and deletion of other SP Objects. In the factory, theparticular version of the trusted drive installs a default means oflogging into the Administration SP. Once the Administration SP Object isinitialized, an authorized agent logs into the Administration SP (step312), and initializes the Controller SP Object with its own accesscontrols (step 314). At this point, it is possible to deny theAdministration SP a right to access, modify, or delete the ControllerSP. Specifically authorized agents can then run testing, diagnostics,and maintenance programs on the controller (step 316).

Ideally, since the factory devices are on an internal factory network,testing can be enabled using the security features of the trusted drive.Specifically, testing is enabled using cryptographic keys storedsecurely on a secure factory server. A handful of trusted drives can beused to secure the factory keys from threats. Either a Microsoft CSP SP,a PKCS#11 SP, or an ISO 7816 SP can provide the security.

In general, the Controller SP may be provided with access controlsadapted to allow the controller to upload new firmware in the field, torun diagnostics, and to run maintenance programs. For example, if thereare original equipment manufacturers (OEMS) with customer-specificdiagnostics, a specific customer can be assigned its own passcode toaccess the diagnostics. The access permissions for this customer mayalso enable the customer to change the passcode, to remove the passcode,or to add cryptographic permission for his diagnostics. The customer caneven set up the Controller SP so that no agent other than the customercan change the customer's access to his particular diagnostics.

In one embodiment, the storage media may be partitioned with a hiddenportion and a data storage portion. In another embodiment, the storagemedia may be partitioned with multiple hidden portions and one or moredata storage portions. In this embodiment, an SP Object may beassociated with a specific storage location on a physical or logicalstorage device. Specifically, each SP Object is associated with its ownlogical partition, which is not available to the OS except throughauthenticated access to the trusted drive firmware on the storagecontroller.

FIG. 4 illustrates a simplified flow diagram of the OEM process. Asshown, in order to integrate a trusted disc drive or storage subsysteminto a platform, the OEM selects which SP Objects it additionally wishesto enable (step 400). For example, on some Trusted drives, there is anSP Objected adapted to provide Host-Drive locking for a storage-enabledtelevision set or a game controller. In this instance, the OEM logs intothe Administration SP (step 402). The OEM then creates a Host-Drivelocking SP with specific access controls (step 404). The access controlsallow only the OEM or his authorized agents to unlock the drive from thehost. The OEM may also install ranges of SPs intended for specificcustomer (step 406). For example, the OEM may install PKCS#11 SPs forserver customers and Microsoft CSP SPs for its desktop customers. TheOEM can then sell the drive and deliver the drive to the customer (step408) either as a storage subsystem or as part of a system, depending onthe specific implementation.

The access controls established by the OEM can be frozen so thatdownstream customers cannot change or modify the features provided.Alternatively, the OEM may allow some of the access controls to bemodified further by a downstream customer.

In general, it will be understood by workers skilled in the art that thepotential number of security providers is without limit. In that regard,the drives or storage subsystems may be assembled and configured withmultiple SPs according to the needs of the specific company or customerfor whom the drives are intended. For example, a company may be providedwith a Checkpoint Virtual Private Network SP, a Microsoft CSP SP, aLotus Notes SP, and a Netscape SP, which can be installed on allplatforms delivered to that company. Each SP object can be installed atthe factory, or at a later time by the OEM, into one or more hiddenpartitions on the drive. Each SP template can be stored in a differenthidden partition, or they may be stored in a single hidden partition.

An Information Technology (IT) manager can configure the trusted drivesor subsystems with additional host security facilities. For example, theIT manager can place specific firewall capabilities on some platformsand may choose to specifically harden access to keystores utilized inhis particular public key infrastructure. He may also choose to deeplyhide password banks that provide access to key company resources. Sincethe SP Objects are easy to create and manage using familiar databasetools, such security measures can be implemented easily. Moreover, theIT manager can provide whole disc encryption where the encryption keysare kept on high security servers.

For an end user such as a home computer user, the drive is provided withan SP application for accessing and enabling or disabling SP objects.The application can, for example, show that the drive includes a“RealNetworks” SP for a company such as RealNetworks, Inc. of Seattle,Wash. (which allows for multimedia file downloads from its web site),offers a discount on audio and video downloads. The end user can thenturn on that SP. Alternatively, if the user is a home user, he or shemay disable all SPs.

If the user is a software developer, he or she may want to develop hisor her own SP Object, perhaps to store some very private informationsuch as his login information for his stock holdings. In this instance,the user may download a software development kit (SDK) from a web sitefrom the OEM or the manufacturer. The user can then write his or her ownSP instance as, for example, an instance of the standard database SP,but requiring RSA Token control for access. The user can then submit theobject code to the web site for the code to be signed, and therebyauthorized to create a SP Object on the Trusted drive. In this instance,the SP is host-side software that is written and installed on the Host.For security reasons, developers are not permitted to write new firmwareand to upload the firmware to the Trusted drive.

Within the Trusted Drive architecture, it is possible to define a SPObject, like the Controller SP, that provides privileged access toauthorized users to upload code to the controller. Thus, customers canbe provided with a “sandbox” where a Sandbox SP can safely executescripts uploaded from the Host on a dynamic basis. A “sandbox” as it isunderstood in this instance is a virtual OS environment, which allowsthe user to upload code into random access memory to run within aconfined window, thereby allowing for code debugging without permanentlyeffecting the trusted drive. Several sandbox applications arecommercially available, including Wave Systems Embassy by Wave SystemsCorp. of Lee, Mass. TCPA/TCGs TPM is being developed to have thiscapability (optionally), and it is likely that the Trusted WindowsPalladium/NGSCB architecture will incorporate a Sandbox for runningarbitrary code. Such a Sandbox SDK would likely be available from thirdparties and not from the disc manufacturer.

FIGS. 5A and 5B illustrate a simplified block diagram of trusted driveimplementation according to an embodiment of the present invention. InFIG. 5A, the hidden portion 500 of the storage media, the main portion502 of the storage media and the partition 504 separating them areshown.

In the embodiment shown, objects stored in the hidden partition portion500 of the storage media are illustrated, including an authority record506 which controls access permissions to the hidden partition 500. Abase class 508 is shown, which is used to instantiate the securityprovider record 510 and access control records 512. The symbol tablerecords 514 defines objects of access associated with the specificsecurity provider record 510, including a list of symbols or names ofobjects that can be accessed by naming them. Symbol types 516 store thetypes of symbols possible, including an SP, a table, a record, a column,an executable, an integer, a string, a real number, a blob, and aBigNum. The last five items are just basic data types supported by SPs.The administration SP controls access to the various SPs containedwithin the SP Record, and any given SP can control access to itself.

The symbol record 514 is just a table within the SP with record columnsfor symbols, types of symbols (stored in related symbol type 516), byteoffsets into the SP (or executable), checksums for integrity checks, andan associated access control table of access control records 512 thatapply to the object named by the symbol. The byte offset generallyallows the byte offset to fully address the contents of the symbol inmemory.

The access control 518 contains a number, a pointer to the user recordcalled the authority record 506, and a statement of the kind of actionspermitted. Each access control instantiation is stored as an ACL record512 with an associated ACL type 520. The actions permitted by accesscontrol 518 include at least the following actions: read, write, modify,and execute.

The symbol table 514 also contains entries for log control 522 andreplication control 524. In general, the log control 522 instructs a logentry to be placed on the success or failure of an access attempt.Replication control 524 instructs a replication copy of an entire SP oran entry in an SP to be made, based on a change to the data pointed toby the symbol.

Finally, initial system tables 526 are shown within the hidden portion500. The initial system tables 526 are created by the manufacturer whenthe partition 504 is created. A data buffer 528 is shown overlapping thepartition 504. The data buffer 528 is utilized by the controller to holdinformation temporarily while access rights are determined.

Turning to FIG. 5B, the storage portion 502 is shown in greater detail.As shown, the base class 508 is provided in the hidden portion 500, butis connected via a line that crosses the partition 504 to a SP base 530within the storage portion 502. The remaining SP objects areinstantiated in the storage portion 502. As shown, the SP lightweightdirectory access protocol (LDAP) 532 and associated LDAP response codes534 are associated with the SP base 530. Additionally, in thisembodiment, and MS CSP standard security feature 536 is provided, whichis associated with the SP base 530.

An SP standard query language (SQL) object 538 links the SP Log 540, theSP registry 542 and its associated registry record 544, and the SPAdministration 546. The storage portion 502 also contains a SP typeobject 548, a store type object 550, and a channel type object 552.

FIGS. 5A and 5B thus illustrate the two storage portions 500 and 502,containing the hidden partition objects and the remaining SP objects.Since literally thousands of companies can provide Host and Networksecurity products, the SP Objects are designed to be independent andself-contained and are designed to utilize a common toolset.

In this embodiment, the media is pre-loaded with SP Object templates anda base class 508. The SP Objects which can then be instantiated usingthe base class 508 and configured utilizing the SP administration 546 toprovide hardened access controls to specific objects, resources,programs, data, and the like. The SP Objects can be varying and complex,and the technique of storing a base class within the hidden portion 508,which can only be accessed by authorized users to instantiate thesecurity provider objects, provides a flexible, versatile system fordelivering and managing digital rights and privacy services fromstorage.

The trusted drive is initialized at the factory with the SP admin and SPcontroller objects, which then provides access to the drive to create SPobjects, initialize them, and configure the drive to provide hardenedsecurity. The consumer, OEM, or other specifically authorized agents canthen be provided with the key for accessing the administration SP inorder to configure the SP Objects or to instantiate additional SPobjects in order to harden security services. Only authorized users arepermitted by the drive to access the protected data, and secureinformation is hidden from the operating system so that the drive datais protected from unauthorized access.

In general, the system and methods of the present invention provideversatile security, digital rights management, and privacy services fromdisc drives and storage subsystems via the storage controllers.Specifically, firmware provided in the storage controllers at thefactory offers hardened security features utilizing SP Objects stored ina hidden partition on the storage media. Since the firmware controllerscan only be updated by authorized users according to the Controller SPsaccess controls, access to the hidden partitions and to the drive itselfare controlled by access controls in the firmware itself. In thismanner, OEMS, IT professionals, and users are free to make use of suchsecurity features as desired, and the trusted drive features can beutilized as desired.

It is to be understood that even though numerous characteristics andadvantages of various embodiments of the invention have been set forthin the foregoing description, together with details of the structure andfunction of various embodiments of the invention, this disclosure isillustrative only, and changes may be made in detail, especially inmatters of structure and arrangement of parts within the principles ofthe present invention to the full extent indicated by the broad generalmeaning of the terms in which the appended claims are expressed. Forexample, the particular elements may vary depending on the particularapplication for the versatile security system while maintainingsubstantially the same functionality without departing from the scopeand spirit of the present invention. In addition, although the preferredembodiment described herein is directed to a system for implementingsecurity providers in a storage system, such as those implementing theMicrosoft CSP security standard or the RSA PKCS#11 security standard, itis expected that such standards will evolve and that new standards maysupplant them. It will be appreciated by those skilled in the art thatthe teachings of the present invention can be applied to any storagesystem implementing trusted drive or other security standards in which asoftware element must be instantiated on the storage device, withoutdeparting from the scope and spirit of the present invention.

1. A method for providing enhanced security features in a storagedevice, the method comprising: partitioning a storage media in thestorage device into a hidden partition and a storage partition in thestorage media; writing a base class to the hidden partition; andinstantiating a security provider base class from the base class, thesecurity provider base class adapted to control access to the storagemedia.
 2. The method of claim 1 wherein the step of instantiatingcomprises: instantiating a SP administration object and a SP controllerobject from the security provider base class; logging into the SPadministration object; and initializing the SP controller object usingthe SP administration object.
 3. The method of claim 2 wherein the SPcontroller object is initialized with access controls.
 4. The method ofclaim 2 wherein the step of initializing comprises: creating an accesscontrol record identifying an user authorized to access the SPcontroller object and access permissions associated with the authorizeduser.
 5. The method of claim 1 wherein before the step of partitioning,the method further comprising: assembling the storage device; writingfirmware to a controller; and powering up the drive.
 6. The method ofclaim 1 wherein the security provider object is a Microsoft CSP securityprovider or a RSA PKCS#11 security provider.
 7. The method of claim 1wherein more than one security provider base class is initialized andwherein each security provider base class is associated with specificstorage location on the storage media, the step of initializing furthercomprising: creating an access control record identifying a userauthorized to access an SP controller object; and creating accesspermissions within the access control record associated with thespecific storage location on the storage media, the access permissionsadapted to control access to the specific storage location.
 8. Themethod of claim 1 wherein the storage device is a disc drive.
 9. Amethod for promoting security in a storage device, the storage devicehaving a processor and firmware adapted to access data stored on astorage media, the method comprising: writing trusted drive firmware toa controller of the storage device; partitioning the storage media ofthe storage device into a hidden portion and a data portion; writing asecurity provider object template to the hidden partition; andinstantiating security providers using the security provider objecttemplate, each security provider adapted to control access to thestorage device.
 10. The method of claim 9 and further comprising:prohibiting access by a host operating system to the storage deviceexcept through authenticated access to the trusted drive firmware of thecontroller.
 11. The method of claim 9 and further comprising:instantiating an administration security provider object and a securityprovider controller object from the security provider object template.12. The method of claim 11 wherein the step of initializing comprises:logging in to the administration security provider object; andinitializing the security provider controller object with accesscontrols using the administration security provider object.
 13. Themethod of claim 11 wherein the administration security provider objecthas one or more authority records stored in the hidden partition, eachauthority record having an associated data set, the method furthercomprising: controlling access to the storage media according to the oneor more authority records.
 14. The method of claim 13 wherein eachobject stored on the storage media is associated with a securityprovider, and wherein the step of controlling further comprises:controlling access permissions to objects stored on the storage mediaaccording to the associated security provider.
 15. The method of claim 9wherein, upon receiving an access request for access to data stored onthe storage device, the method further comprising: querying a requestingdevice for trust information; determining whether the remote device canbe trusted using the trusted drive feature and an instantiation of thesecurity provider object template; and if the remote device can betrusted, permitting storage controller access to a specific storagelocation.
 16. A storage device for providing hardened security featureshaving a storage media partitioned into a hidden portion and a dataportion and having a storage controller adapted to control access to thestorage media, the storage device comprising: a trusted drive featurestored in a firmware of the storage controller, the trusted drivefeature adapted to authenticate access requests to determine whethereach access request can be trusted; and a SP base object stored in thehidden portion and adapted to cooperate with the trusted drive featureto control access rights to data on the storage media.
 17. The storagedevice of claim 16, and further comprising: one or more instantiatedsecurity providers stored in the hidden portion of the storage media,each instantiated security provider associated with a particular area onthe storage media.
 18. The storage device of claim 17 wherein the SPbase is invoked to create a SP administration object and a SP controllerobject, the SP administration object is adapted to configure associatedsecurity provider objects, the SP controller object is adapted tocontrol access to a particular area on the storage media.
 19. Thestorage device of claim 16 and further comprising: a trusted driveauthorizing public key store adapted to cryptographically verify arequest for a new security provider instantiation.
 20. The storagedevice of claim 16 and further comprising: a key and passcode revocationstore adapted to check keys, passcodes, or other authenticators forrevocation.
 21. The storage device of claim 16 and further comprising: aregistry security provider adapted to provide a standard securityprovider handle through which any number of physical copies of asecurity provider can be located and managed.
 22. The storage device ofclaim 16 and further comprising: a hardened log SP adapted to track andlog the activity of other security providers based on successes andfailures to gain access to data controlled by the other securityprovider.
 23. The storage device of claim 16 and further comprising: aclock time security provider adapted to provide a hardened clock sourceto other devices and/or to other security providers.
 24. The storagedevice of claim 16 and further comprising: a diagnostics securityprovider adapted to harden access to storage controller diagnostics. 25.The storage device of claim 16 and further comprising: a test securityprovider adapted to harden access control to storage controller testing.26. The storage device of claim 16 and further comprising: an externalcode security provider adapted to harden access control to softwarerunning on the security provider.
 27. A storage device comprising: astorage media comprising a plurality of partitions, one or more of thepartitions being hidden from a host operating system; a controllercoupled to the storage media and to controller firmware, the controlleradapted to read and to write data to and from the storage media; atrusted drive feature stored in the controller firmware; and one or moresecurity provider objects stored in the one or more hidden partitions,each security provider object cooperating with the trusted drive featureto restrict unauthorized access to data stored on the storage media. 28.The storage device of claim 27 wherein the trusted drive featureauthenticates data access requests to determine whether each accessrequest is received from a trusted entity according to access rightsstored in the one or more hidden partitions.
 29. The storage device ofclaim 27 wherein each security provider object is stored in a hiddenpartition related to the security provider object.
 30. The storagedevice of claim 27 wherein the security provider object comprises: abase security provider class.
 31. The storage device of claim 30 whereinthe base security provider class comprises: an security provideradministration object constructor for instantiating an administrationobject to configure associated security provider objects; and a securityprovider controller object constructor for instantiating a controllerobject to cooperate with the trusted drive feature to control access toa particular area on the storage media.
 32. An enhanced security featurefor use in a storage device having a storage media and a controller, theenhanced security feature comprising: a trusted drive feature stored infirmware of the controller of the storage device, and a securityprovider stored in a hidden partition defined on the storage media, thesecurity provider cooperating with the trusted drive feature to controlaccess to data stored on the storage media.
 33. The enhanced securityfeature of claim 32 wherein the trusted drive feature authenticatesaccess requests to determine whether each access request can be trusted.34. The enhanced security feature of claim 32 wherein the securityprovider comprises: a security provider administration object foradministering security provider settings; and a security providercontroller object for managing access controls associated with portionsof the storage media.
 35. The enhanced security feature of claim 32wherein the security provider comprises a software algorithmimplementing a standard security protocol.